We probably should accept the lowercase

I suspect a commit that would permit lowercase spelling of those (I assume along with the current widely-used spelling) would be impossible to get through considering the places it would touch (Clang.cpp, MSVC.cpp, Flang.cpp, a number of places in CommonArgs.cpp, and of course Options.td). Adding std::tolower on each relevant string comparisons in the C++ files would look uncomfortable enough, but adding lowercase counterparts to each available veclib option in the Options.td file would look even more uncomfortable (and concerning to the most of the reviewers). IMO this is not the right thing to do. The milk is spilled, the current spellings of these options were accepted by reviewers, the users have made uses of this spelling, now the only thing we can do is to make the documentation reflect that.

Changing the spelling to all-lowercase (to match with the documentation) is also no-go area: people wrote Makefiles and other codebase artifacts using the current spelling. The veclib flags are mostly used by HPC apps, they tend to be large, people will be cursing if we do a change which will force them to make changes in their chunky build scripts.

Adding std::tolower on each relevant string comparisons in the C++ files would look uncomfortable enough,

We have StringRef::equals_insensitive

but adding lowercase counterparts to each available veclib option in the Options.td file would look even more uncomfortable (and concerning to the most of the reviewers).

I don't see how this is burdensome

We have StringRef::equals_insensitive

We do. But using == operator for a string comparison always looks better. I won't be arguing on this though, as I'm seeing it (the StringRef::equals_insensitive) used frequently throughout the frontend driver code. But then, what would you do about this?:

  // List of veclibs which when used with -fveclib imply -fno-math-errno.
  constexpr std::array VecLibImpliesNoMathErrno{llvm::StringLiteral("ArmPL"),
                                                llvm::StringLiteral("SLEEF")};

...

    case options::OPT_fveclib:
      VecLibArg = A;
      NoMathErrnoWasImpliedByVecLib =
          llvm::is_contained(VecLibImpliesNoMathErrno, A->getValue());
      if (NoMathErrnoWasImpliedByVecLib)
        MathErrno = false;

There's no llvm::is_contained_case_insensitive available, so what would be a good LLVM idiom for handling this?

NB: this is one of the places I have spotted, I wonder how many other places will be affected non-obvious way if we allow case insensitive spelling of the names which were used in their current forms for the last few years...